[レポート] Threat detection and response using AWS security services に参加してきました! #SEC301 #AWSreInvent
こんにちは! AWS 事業本部オペレーション部の平根です。
re:Invent 2024 の Workshop 「Threat detection and response using AWS security services」に参加してきましたので内容をご紹介します。
セッション概要
セッションタイトル
SEC301 | Threat detection and response using AWS security services
セッションの説明
※機械翻訳
AWSのセキュリティエキスパートと共に、ネイティブのセキュリティサービスを使用して、様々なワークロード全体の脅威を検出・対応する実践的なワークショップに参加しましょう。一般的な脅威の種類、その検出方法、対応の優先順位付けについて学びます。このワークショップでは、異なるリソースや動作にわたる複数のセキュリティイベントをシミュレーションします。提供されるサンドボックス環境で実際に手を動かし、シミュレーションされたイベントから得られた発見事項を確認し、対応します。参加にはノートパソコンの持参が必要です。
スピーカー
- Ray Elkins
- Senior Solutions Architect, Amazon Web Services
- Nicholas Jaeger
- Principal, Security SA, AWS
Level
300 – Advanced
事前説明
初めに、今回のワークショップで取り扱う以下の AWS の主要なセキュリティサービスについて概要の説明がありました。
- Amazon GuardDuty
- 機械学習(ML)や脅威インテリジェンスを活用したサービスであり脅威検出や検出した脅威の重要度を分類するサービス
- VPN Flow Logs, DNS Logs, CloudTrail イベントなどのロギングサービスをデータソースとして活用して脅威を検出する
- Amazon Detective や AWS Security Hub など、他のセキュリティサービスと統合可能
- Amazon Detective
- 潜在的なセキュリティの問題や不審なアクティビティの根本原因を分析、調査可できるサービス
- AWS リソースからデータを収集し、機械学習や統計分析、グラフ理論を活用してデータセットを構築することでより迅速で効果的なセキュリティ調査を実現
- AWS Security Hub
- クラウドセキュリティの体制管理サービス
- AWS サービスや サードパーティサービスでの検出結果をシームレスに統合し、セキュリティ対応の自動化を可能にする
- セキュリティのベストプラクティスを継続的にチェック
Workshop 演習項目
以下が本 workshop の演習項目です。
AWS のセキュリティサービスの概要から自動化、シミュレーションといった非常に内容盛りだくさんの Workshop となっており、全て実施をすると 10 時間程度かかる旨の説明がスピーカーからありました。
Workshop の時間は 2 時間であるため、全て実施することは難しそうです。
※タイトルは機械翻訳
-
セクション 0: 脅威検出および対応サービスの概要
- Amazon GuardDuty
- Amazon Detective
- AWS Security Hub
- Amazon Inspector
- AWS IAM Access Analyzer
-
セクション 1: AWS サービスとパートナーソリューションの統合
- AWS セキュリティサービスからの調査結果を一元管理
- AWS パートナーソリューションからの調査結果を一元管理
- 地域間の集約を見つける
- 独自のセキュリティハブ統合を構築する
-
セクション 2: セキュリティ調査結果の管理と優先順位付け
- 自動化による大規模な調査結果の優先順位付け
- 自動化による大規模な発見の抑制
- 優先順位付けと指標に洞察を活用する
-
セクション 3: 通知と応答の自動化
- 通知の設定
- 毎週の脆弱性概要メールを設定する
- AWS での自動セキュリティ対応
- 独自の自動応答を構築する
- 調査データによるセキュリティ調査結果の充実
-
セクション 4: セキュリティ シミュレーションとシナリオ
- IAM ロール認証情報の流出への対応
- 侵害された S3 バケットに対応する
- 侵害されたIAM認証情報への対応
- 悪意のあるIPを呼び出すLambda関数に応答する
- Amazon Elastic Block Store のマルウェアへの対応
- 侵害されたEC2インスタンスに対応する
- パブリックアクセスで SQS キューに応答する
-
セクション 5: ソフトウェア脆弱性管理
- パッチマネージャを使用した EC2 へのパッチ適用
- サーバーレスアプリケーションの脆弱性管理
- Amazon Inspector を CI/CD パイプラインに統合する
GuardDuty や Detective の利用経験がある場合にはセクション 4 の内容を実施を推奨するとの説明がありました。
私はセクション 0 の内容に含まれる Detective や Inspector の利用経験に乏しかったため、セクション 0 から実施しました。
セクション 4 では擬似的に IAM ロールが漏洩したケースを再現したシナリオや EC2 が侵害されているシナリオなど、より実践的な対応について学習できるハンズオンとなっております。
セクション 4 を実施したセッションレポートについては以下に紹介されておりますのでご参照ください。
以降は私が実施したセクション 0 についてレポートとります。
セクション 0: 脅威検出および対応サービスの概要
Amazon GuardDuty
GuardDuty での検出結果の見方やフィルタリング方法、アーカイブ方法など検出結果の基本的な取り扱い方法について学習しました。
また、以下の機能については実際に検出結果を出力させるテストを行いました。
- S3 マルウェア保護
S3 マルウェア保護を有効化し、保護対象の S3 バケットにマルウェア検知テストのための EICAR テストファイルをアップロードしました。
以下のように検出されました。
EICAR テストファイルをアップロード後、数分もしないうちに以下のように MaliciousFile として検出されました。
- EC2 ランタイムモニタリング
EC2 ランタイムモニタリングでは、インスタンスレベルでのファイルアクセス、プロセス実行、ネットワーク接続などの問題を検知します。
本ハンズオンにて EC2 ランタイムモニタリングを有効化すると、以下のように全てのインスタンスが Unhealty となっていることが確認できました。
Unhealty となっているインスタンスのうち、問題のタイプが "No Agent Reporting" のものについて、調査を行います。
上記のメッセージから AWS Systems Manager との接続に問題がありそうです。
トラブルシューティングにあたっては、AWS Systems Manager Automation Runbook の AWSSupport-TroubleshootManagedInstance [1] を利用しました。
[1]:AWSSupport-TroubleshootManagedInstance
Runbook の実行後は以下が出力されました。
エラーメッセージに "No permissions found attached to the EC2 instance profile" とあることから、インスタンスに適切な権限が設定されていないことがわかります。
対象インスタンスに設定された IAM ロールを確認すると、エラーメッセージの通り権限が設定されていませんでした。
上記の IAM ロールに "AmazonSSMManagedInstanceCore" ポリシーを設定し、インスタンスを再起動することで、対象インスタンスのステータスが Healthy に変化しました。
また、本項目では EventBridge のルールで以下のイベントパターンを設定し、重大度が MEDIUM および HIGH の検出結果を SNS へ通知する設定を実施しました。
イベントパターン
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [
4, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9,
5, 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9,
6, 6.0, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 6.9,
7, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9,
8, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9
]
}
}
Amazon Detective
Amazon Detective にて、現在 Workshop で利用している IAM ロールである "WSParticipantRole" の調査を行いました。
以下のように成功した呼び出し、失敗した呼び出しについて検出されていることを確認しました。
また、別の IAM ロールについて調査レポートのを出力をおこないました。
サマリーとして、調査対象のロールに異常な動作が確認された旨の結果が出力されました。
今回の Workshop ではこれ以上の詳細な調査は行いませんでしたが、調査結果に出力された疑わしい IP アドレス等に着目してより詳細な調査が可能です。
AWS Security Hub
Security Hub のダッシュボードや検出結果の確認方法について学習しました。
重大度ラベルでのフィルタリング、リソースタイプでの検出結果の絞り込みなど検出結果の基本的な検索方法について学習しました。
また、EventBridge のルールで以下のイベントパターンを設定し、重大度が Critical とラベル付けされた検出結果について、通知を行うように設定をしました。
イベントパターン
{
"source": [
"aws.securityhub"
],
"detail-type": [
"Security Hub Findings - Imported"
],
"detail": {
"findings": {
"ProductName": [
"Security Hub"
],
"Severity": {
"Label": [
"CRITICAL"
]
}
}
}
}
Amazon Inspector
Amazon Inspector のダッシュボードの確認方法や検出結果の確認方法について学習しました。
特定のリソースタグ指定による検出結果のフィルタリングや CWE, CVE などの脆弱性に基づいた検索を行いました。
本項目を実施している途中でタイムアップとなり、本項目の 1 部や 残りの項目である AWS IAM Access Analyzer の項目は実施できませんでした。
ためになったこと
EC2 ランタイムモニタリングの結果でインスタンスが Unhealthy となっている際に利用したトラブルシューティング用の Runbook が非常に便利だと感じました。
トラブルシューティング向けの Runbook は AWS Support Automation Workflows (SAW) として提供されています。
参考
AWS Support Automation Workflows(SAW)Runbook が 70個に増えていた! とっておきの SAW と出会えるかもしれない!- DevelopersIO
セキュリティサービス等のモニタリングでリソースの修正が必要と検知された場合には、利用可能な際には SAW を積極的に利用してみようと思いました。
最後に
本 Workshop への参加は、AWS のセキュリティサービスの基本を理解・再確認するのに良い機会となりました。
セキュリティサービスに幅広く触れてみたいかたや、実践的なシナリオを想定した修復の対応について学習したい方には非常におすすめの Workshop です。
この記事がどなたかの参考になれば幸いです。
以上、平根でした!